In the field of test data management, application testing requires test data. The test data is either created from beginning or retrieved from a production database. The application testing comprises execution of test cases and execution of each of the test case leads to modification in the test data.
During testing, developers or testers (referred to herein collectively as testers) intend to view the changes in data after a test case is executed. This helps testers verify success of execution of the test case. If the data is right, they can mark execution of the test case as successful. If the data is wrong, it means execution of the test case has failed and they would like to rollback changes in a data table to its original state. Conventionally, the testers execute structured query language (SQL) queries manually on the test database in order to find the changes made in the test data. While executing the queries, the testers utilize table viewers provided by the database. One example is a SQLPLUS utility provided by Oracle. The table viewers are user interfaces or tools to view the test data in a tabular form. The table viewers provide the latest data in the database table without providing information on the latest changed values (so that a tester may perform a comparison between different states of the database or different test stages). Executing queries by using the user interfaces is a manual task and, at the same time, is time consuming thereby bringing in a possibility of errors.
Conventionally, one approach for test data versioning in database application development is based on long transaction management. The approach enables multiple logically consistent and mutually exclusive logical databases which are to be maintained simultaneously in the same database. In this approach, each developer works on their own long transaction and separates them from changes performed by others developers.
Further, long transaction is performed using low level versioning. A database table version is enabled by augmenting its key with a version number. The changes performed in the long transaction are tagged with version numbers that are unique to the long transaction. A view named VersionTree view is created on each version enabled table. In order to achieve this, an original table is renamed and the VersionView with the same name as that of the table is created. Long transaction approach creates new entities in the database in order to create a logical database which increases data in a test environment. Further, the long transaction approach is specific for certain type of databases.
Further, the testers spend time in verifying the data change in the test database after test execution. In order to compare the data after execution with the original data, the testers have to perform manual tasks. In addition, during verification processes, the testers may find issues in the modified data in the database because of the errors present in the application that require rerunning of the application after the error is fixed. In such case when the developers have to test using the original data instead of the data resulting from the previous round of testing, rerunning of the application is not possible because original data stage is not saved. Further, the original data stage is a first stage while testing the data. In such cases, the developers have to perform manual tasks in order to revert to original data stage for running the test case. The manual tasks so performed are time consuming and may lead to inaccuracy. Because of the absence of comparison between the old data and the new data at the time of test execution, some critical changes may get missed due to manual comparison and analysis, and this will result in errors.
The test case verification or accuracy evaluation is done by comparing the changes made by the application being tested during various test stages. The other approach used by the testers in order to verify the test case of the earlier stage is by fixing the improper data manually or refreshing the test environment. Fixing the improper data manually is more prone to errors and refreshing of the test environment is time consuming. Refreshing of the test environment is an option, but that will take test data to its original stage. Testers may have to rerun all the test cases to get data into a stage where the last failed test case can be rerun. This can be time consuming.
Existing databases provide change in data in the form of log files. When a certain amount of data storage is logged in the log file the database logs into a next file to maintain various stages of the data. Further, the database facilitates reverting back to an identified stage as specified in the log file. In such cases, the developers do not have access to such log files.